Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/commands/install/all.ts`:
- Around line 57-59: Move the deps.ensureRuntimeEnv() call and depsRoot
assignment from its current position at line 57 to after the flow target
detection logic (after the hasWeb and hasAndroid checks around lines 73/82).
This ensures runtime environment resolution only occurs when there are actually
installable flows (web or android targets present), preventing unnecessary
managed installs or install failures when only iOS flows or no flows exist.
Update any references to depsRoot to use the value obtained from the deferred
ensureRuntimeEnv call.

In `@src/commands/install/browsers.ts`:
- Around line 21-41: The runtime environment resolution via ensureRuntimeEnv is
being called too early before confirming whether browser flows actually exist.
Move the ensureRuntimeEnv call and the subsequent resolvePlaywrightCli call to
execute lazily after browser targets have been confirmed to exist. This defers
unnecessary work when browser collection is a no-op and prevents offline
failures on otherwise skippable runs. Identify where browser targets are
actually validated in the flow and relocate the depsRoot resolution and runtime
environment setup to occur only after that point.

In `@src/domains/runtimeEnv/ensureRuntimeEnv.ts`:
- Around line 64-65: After the install(managed) call completes successfully, add
a validation check to ensure all pinned dependencies are actually resolved
before returning installed: true. Use the allPinnedResolved function to verify
that the install operation fully materialized the pinned deps for the managed
depsRoot. If the validation check fails, throw an error or fail fast to prevent
reporting success when dependencies were not fully installed.

In `@src/domains/runtimeEnv/installPinned.ts`:
- Around line 35-40: The readiness check in the `installPinned` function at line
35-40 uses `existsSync` to verify that `node_modules/.bin/playwright` exists,
but this is insufficient because the binary could exist while pinned versions
are missing or mismatched. Replace the `existsSync` check on the playwright
binary path with a call to `allPinnedResolved` to properly validate that all
pinned dependencies are correctly installed and resolved. Apply the same fix to
the duplicate check mentioned at lines 64-67.
- Around line 52-54: The error message in the Error constructor that handles
failed managed runtime installation is directly interpolating raw stderr output
from npm, which can expose sensitive information. Replace the raw
`result.stderr.trim()` in the thrown error message with a generic sanitized
error summary. If detailed stderr information is needed for debugging, move the
raw stderr to a separate debug logging call using controlled logging paths,
keeping the thrown error message safe and user-facing while preserving debugging
capabilities.

In `@src/domains/runtimeEnv/resolvePinned.ts`:
- Around line 38-40: In the resolvePinned.ts file, the fs.existsSync check that
verifies the playwright binary existence only looks for the extension-less
playwright script. Modify this condition to check for both the extension-less
variant and the .cmd variant (playwright.cmd) since Windows npm/bun
installations create the .cmd shim alongside or instead of the extension-less
version. Update the condition to return false only if neither variant exists,
allowing the check to properly detect Playwright installations on both Windows
and POSIX systems.

---

Outside diff comments:
In `@src/domains/runner/initFlowRuntime.ts`:
- Around line 116-123: The initCache key in the initFlowRuntime function only
includes startDir, but doInit receives both startDir and options.depsRoot as
parameters. When the same directory is initialized with different depsRoot
values, the cache incorrectly reuses the first initialization. Create a
composite cache key that combines both startDir and options.depsRoot, then use
this composite key in both the initCache.get() call and the initCache.set() call
to ensure different depsRoot values for the same directory produce separate
cache entries.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/commands/doctor/handler.ts`:
- Around line 44-47: The issue is in the resolveDepsRootIfPresent call where
when projectDir is undefined, an empty object is passed as the second argument
instead of providing a fallback. When resolveProjectDirSafe returns undefined,
you should provide the current working directory (cwd) as a fallback value for
projectDir in the ternary operator passed to resolveDepsRootIfPresent, so that
it can still probe for dependencies in the current workspace instead of skipping
the project probe entirely and only checking managed runtime.

In `@src/domains/flows/ensureDeps.ts`:
- Around line 43-46: The catch block around the resolveUniqueEnvDir function
call is too broad and silently masks all errors, including unexpected filesystem
or logic errors. Narrow the catch block to only handle the expected
multi-package conflict error by checking the error message or type before
returning undefined. For unexpected errors, re-throw them so they surface as
actual failures rather than silently falling back to managed runtime. Ideally,
work with the resolveUniqueEnvDir function to use a dedicated error class or
code for the multi-package conflict scenario and match against that specific
error type instead of catching all exceptions.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/domains/runtimeEnv/managedEnvDir.test.ts`:
- Around line 42-46: The test assertion on the line with
expect(managedEnvDir()).toBe() is comparing against join("/custom/cache", hash)
but managedEnvDir() actually returns join(resolve("/custom/cache"), hash) as
shown in managedEnvDir.ts line 30. On Windows, resolve() adds a drive prefix
which causes the path mismatch. Update the expectation to use
resolve("/custom/cache") when calling join to match the actual behavior of
managedEnvDir() function and ensure the assertion correctly validates the
implementation across all platforms.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/domains/flows/stageFlows.test.ts`:
- Around line 113-127: The test verifies that the staged file exists after
re-running stageFlows but does not verify that the updated content is actually
picked up. Add an assertion that reads the content of the staged file at
join(second.bundleRoot, "a.flow.ts") and verifies it equals "v2" (the updated
content), not "v1" (the original content), to ensure that edits to the original
flow file are properly reflected in the staged directory.

In `@src/domains/flows/stageFlows.ts`:
- Around line 42-45: The stagedDir variable is derived deterministically from
hashProjectDir, which causes concurrent runs with the same projectDir to collide
and delete each other's staging directories mid-execution. To fix this, modify
the stagedDir construction to include a unique identifier per run (such as a
timestamp or UUID) in addition to the hash, ensuring each concurrent execution
gets its own isolated staging directory that won't be removed by other
simultaneous runs. Alternatively, implement a file-based locking mechanism
around the fs.rm and fs.mkdir operations to serialize access to the same staging
directory across concurrent runs.

In `@src/domains/runtimeEnv/clearRuntimeEnv.ts`:
- Around line 12-14: The clearRuntimeEnv function performs a recursive deletion
on a directory path obtained from managedEnvBaseDir() without verifying it is
actually a managed runtime directory, which could lead to accidental deletion of
unrelated data if the environment override is misconfigured. Add validation
logic before the fs.rm call to verify the directory is a legitimate managed
runtime location (using a sentinel file or layout validation), and skip or fail
the deletion operation if validation is missing or fails. This ensures the
function fails closed and protects against dangerous deletions.

In `@src/domains/runtimeEnv/linkManagedDeps.ts`:
- Line 33: The symlink call in linkManagedDeps.ts is hardcoded to use "dir"
which requires administrator privileges on Windows. Replace the hardcoded "dir"
string with platform-aware logic that checks the current operating system: use
"junction" for Windows (which requires no elevated privileges) and "dir" for all
other platforms. The same conditional logic should also be applied to the
corresponding symlink call in the test file linkManagedDeps.test.ts at line 83
to keep the tests platform-aware and consistent with the production code.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/commands/flows/hybridRun.test.ts`:
- Line 55: The in-memory filesystem created by makeMemoryFs() is empty, causing
resolveProjectDirSafe() to return undefined and stageFlows() to skip the
staging/linking/cleanup path that needs to be tested. Seed the ctx.fs with the
necessary mocked project/environment files (such as configuration files or
manifest files that the project resolution logic expects) before calling the
functions that depend on resolveProjectDirSafe(), or alternatively create a
focused test case with a resolvable project directory structure.

In `@src/commands/flows/hybridRunDefaults.ts`:
- Around line 115-124: The current condition for linking managed dependencies at
the `linkManagedDeps` call is too restrictive - it checks both
`runtimeEnv.source !== "project"` and `staged.bundleRoot !== undefined`, which
means dependencies are skipped when bundleRoot is undefined or when source is
"project". This causes hybrid runs to load flows without the properly resolved
depsRoot. Remove the `runtimeEnv.source !== "project"` check so that
`linkManagedDeps` is invoked whenever `staged.bundleRoot` is defined,
guaranteeing that all hybrid runs have access to the managed dependencies
through the deps root selected by resolveDepsRoot.

In `@src/commands/flows/runDefaults.ts`:
- Around line 101-109: The condition for calling linkManagedDeps is too
restrictive and only executes when runtimeEnv.source is not "project". This
fails to ensure that staged flows always resolve imports from the correct deps
root. Modify the if condition to link whenever staged.bundleRoot exists,
regardless of the runtimeEnv.source value. Remove the source check so that
linkManagedDeps is called for all cases where a bundleRoot is available,
ensuring managed and override fallbacks are properly linked to
runtimeEnv.depsRoot.

In `@src/domains/runtimeEnv/clearRuntimeEnv.test.ts`:
- Around line 51-52: The test currently uses
expect(clearRuntimeEnv(fs)).rejects.toThrow() without properly settling the
promise before the dependent assertion on the next line. Replace the
expect().rejects pattern with an explicit try/catch block where you await the
clearRuntimeEnv(fs) call in the try block, then in the catch block verify the
error message contains "Refusing to delete" using an expect statement. Only
after the try/catch block completes should the filesystem assertion checking
fs.pathExists(override) execute, ensuring all dependent state checks run after
the promise has fully settled.

---

Outside diff comments:
In `@src/commands/flows/hybridRunDefaults.ts`:
- Around line 115-134: The staged cleanup is registered too late, after
operations that can throw (linkManagedDeps, configureTestkit, createAndroidDeps,
runWebFlowDeps), which can leak the staged .qawolf/.local tree if those
operations fail. Move the cleanup registration immediately after the
stageFlows() call completes, then wrap all subsequent code in a try/finally
block that calls unregisterCleanup to ensure cleanup runs regardless of whether
later operations throw.

In `@src/commands/flows/runDefaults.ts`:
- Around line 101-119: The cleanup registration using staged.cleanup happens too
late in the function, after stageFlows, linkManagedDeps, configureTestkit, and
runWebFlowDeps have already been called. If any of these operations throw an
error before reaching the cleanup registration at the end, the staged tree will
be left behind. Move the unregisterCleanup initialization to immediately after
the stageFlows call completes, then wrap all the remaining operations
(linkManagedDeps, configureTestkit, createAndroidDeps, runWebFlowDeps, and any
subsequent code) in a try/finally block to ensure cleanup is always registered
and executed.

In `@src/domains/runner/runWebFlow.ts`:
- Around line 44-47: The initFlowRuntime function in
src/domains/runner/initFlowRuntime.ts uses initCache keyed only by
path.dirname(flowPath), but the doInit function now uses options.depsRoot to
import the _runner dependency. This means different runs of the same flow
directory with different depsRoot values will incorrectly reuse the cached
runtime from a previous run with a different dependency root. Update the cache
key generation to include both path.dirname(flowPath) and options.depsRoot so
that each unique combination of flow directory and dependency root has its own
cached runtime instance.